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ABSTRACT 

The overall goal of the 2 nd Generation RLV Program is to substantially reduce 
technical and business risks associated with developing a new class of reusable 
launch vehicles. NASA’s specific goals are to improve the safety of a 2 nd - 
generation system by 2 orders of magnitude — equivalent to a crew risk of 1 -in- 
10,000 missions — and decrease the cost tenfold, to approximately $1,000 per 
pound of payload launched. 

Architecture definition is being conducted in parallel with the maturating of key 
technologies specifically identified to improve safety and reliability, while reducing 
operational costs. An architecture broadly includes an Earth-to-orbit reusable 
launch vehicle, on-orbit transfer vehicles and upper stages, mission planning, 
ground and flight operations, and support infrastructure, both on the ground and 
in orbit. The systems engineering approach ensures that the technologies 
developed — such as lightweight structures, long-life rocket engines, reliable 
crew escape, and robust thermal protection systems — will synergistically 
integrate into the optimum vehicle. To best direct technology development 
decisions, analytical models are employed to accurately predict the benefits of 
each technology toward potential space transportation architectures as well as 
the risks associated with each technology. Rigorous systems analysis provides 
the foundation for assessing progress toward safety and cost goals. 

The systems engineering review process factors in comprehensive budget 
estimates, detailed project schedules, and business and performance plans, 
against the goals of safety, reliability, and cost, in addition to overall technical 
feasibility. This approach forms the basis for investment decisions in the 2 nd 
Generation RLV Program’s risk-reduction activities. Through this process, NASA 
will continually refine its specialized needs and identify where Defense and 
commercial requirements overlap those of civil missions. 



1.0 Background 


The U.S. Space Launch Initiative (SLI) is the central focus of the National 
Aeronautics and Space Administration’s (NASA) Integrated Space Transportation 
Plan (ISTP), a comprehensive strategy for revolutionizing space transportation in 
the 21 st century. The ISTP includes: (1) Space Shuttle Safety Upgrades, (2) near- 
term investments in 2 nd Generation Reusable Launch Vehicles (RLV), and (3) 
long-term research for 3 rd Generation RLVs and In-Space Transportation 
systems for future space exploration. 

Building on 20 years of success with America’s 1st Generation RLV — the Space 
Shuttle — the SLI defines the plan of action to design space transportation 
systems and develop advanced technologies for America’s next-generation RLV. 
It addresses business risk reduction for 2 nd Generation RLV development and 
technology risk reduction for NASA-unique systems (i.e., crew survival features), 
as well as enables potential Alternate Access to the International Space Station 
(ISS). Therefore, SLI is synonymous with the 2 nd Generation RLV Program, 
which is managed by NASA’s Marshall Space Flight Center (MSFC), with 
participation from NASA field Centers and aerospace contractors from coast to 
coast. 

The 2 nd Generation RLV Program’s scope is not limited solely to the launch 
vehicle, but encompasses all elements of a space transportation system 
architecture, an integrated set of elements consisting of: 

1 . Earth-to-orbit launch vehicle 

2. On-orbit transfer vehicles and upper stages 

3. Mission planning 

4. Ground and flight operations 

5. Ground-based and on-orbit support infrastructure. 

Figure 1 illustrates the interrelated nature of these elements, which function 
synergistically to accomplish the space transportation mission. 

The 2 nd Generation RLV Program is based on the philosophy that frequently 
launching NASA payloads on highly reliable reusable launch vehicles will 
significantly reduce the cost of space access, allowing the Agency to focus 
resources on its core missions of scientific discovery and exploration. [1] Overall 
goals are to substantially reduce technical and business risks associated with 
developing safe and reliable RLVs. NASA’s specific goals are to: 

• Improve safety — risk of crew loss — to less than 1 -in-1 0,000 missions 

• Decrease cost by a factor of 10 — to approximately $1 ,000 per pound of 
payload launched to low-Earth orbit (LEO). 
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Legend: 

CTV — Crew Transfer Vehicle 
OTV — Orbital Transfer Vehicle 
OCTV — Orbital Crew Transfer Vehicle 
ISSMM — International Space Station 
Multipurpose Module 


Figure 1 . Space Transportation System elements. 


Therefore, NASA is investing in strategic technology development in these areas 
for the express purpose of increasing safety and decreasing cost. While the 
space transportation architecture drives specific technology developmental 
objectives, the technologies ultimately enable the space transportation 
architecture. This cross-cutting character of space transportation technology 
development, viewed against a backdrop of multiple vehicle designs, is depicted 
in Figure 2. 
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Figure 2. Space Transportation System technology and design 
development. 

The systems engineering and integration task consists of two distinct activities to 
be accomplished during the formulation phase covered by the 2 nd Generation 
RLV Program: 

1. Conduct System Studies — Define and comparatively evaluate candidate 
space transportation architectures, and develop and validate the 
associated systems requirements. 

2. Coordinate Technology Developments — Maintain a technology portfolio 
to support evolving space transportation architecture(s). 

Following is a description of the top-level systems engineering and integration 
processes developed to define a viable RLV architecture and mature the key 
technologies that will enable that architecture to meet Program objectives 


2.0 Systems Engineering Process Overview 





The overall systems engineering and integration process is illustrated in Figure 5. 
System definition begins with communication with customers and stakeholders. 
The Program solicits customer and stakeholder needs and wants, and provides 
space transportation system capabilities and costs as feedback. The systems 
definition activity quantifies customer needs and wants in terms of Level 1 
Program Requirements and design reference missions (DRM), and quantifies 
system capabilities and costs in terms of mission-level figures of merit (FOM) — 
measures to which customers and stakeholders can relate. This activity also 
articulates the space transportation system’s intended usage scenario in a 
Operations Concept Document for the architecture. 



Figure 3. Systems engineering and integration process. 


The systems requirements activity takes the system definition and develops a 
requirements allocation and flow-down for the space transportation system. This 
is the key integrating mechanism for the Program. It includes requirements 
synthesis with the individual projects within the advanced technology portfolio. 

Given a requirements basis for a space transportation system, the systems 
analysis activity validates the requirements, using a design analysis cycle (DAC) 
process. The feedback provided indicates which requirements are valid and 
which are not; this information, in turn, influences the technology portfolio or may 






even affect Level 1 Requirements. The output of a design analysis cycle will also 
include the mission-level figures of merit in support of the system definition 
activity. Over time, successive cycles will result in convergence to the optimal 
space transportation system architecture, as illustrated in Figure 6. 
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Figure 4. Convergence to the optimal Space Transportation System 
architecture. 


3.0 Technology Integration 

The space transportation architecture will achieve the goals of increased safety 
and reduced costs only through advancements in the state-of-the-art in several 
key technology areas. These key technologies include: 

■ propulsion and upper stages, 

■ thermal protection systems (TPS), airframes, and large cryogenic tanks 

■ avionics and vehicle subsystems, 






■ crew escape and survival, 

■ flight mechanics, 

■ integrated vehicle health management (IVHM), and 

■ operations. [2] 


The progress in maturing the respective technologies is determined through 
periodic assessment of the technological readiness at various stages with a 
numerical grade. A numerical value of 1 signifies the starting of the program and 
a value of 9 represents full technological readiness, indicating 100% confidence 
in the mission performance of a technology. An exit criteria can be set at some 
value between 1 and 9 that corresponds to design readiness - that is, the 
technology, while not yet fully proven, is mature enough to include in the system 
design with an acceptable degree of risk. The following technology readiness 
criteria provide a numerical grade by way of require ments to be met at each level 
of technology maturation are defined below 
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1. Basic pinciples observed and reported 

2. Technology concept and /or application formulated (candidate selected) 

3. Analytical & experimental critical function, or characteristic proof-of- 
concept, or completed design 

4. Component and/or breadboard test in a laboratory environment 

5. Component (or breadboard) verification in a relevant environment 

6. System/Subsystem (configuration) model or prototype demonstrated 
and/or validation in a relevant environment 

7. System prototype demonstrated in flight 

8. Actual system completed and “flight qualified” through test and 
demonstration 

9. Actual system “flight proven” on operational flight 

The following sections discuss the establishment of target performance 
requirements for technologies, the monitoring of progress in achieving 
technology requirements, and the overall systems analysis process which assess 
the technology risk and payoff within the context of the evolving space 
transportation architecture. 


3.1 Technology Requirements Development 

A Systems Requirements Document (SRD) will be developed to describe an 
architecture’s technical, operational, and support requirements, and the 
allocation of the system requirements to the five architectural elements (see 
Section 1.0), as well as to define the interfaces between the architectural 
elements. Inextricably coupled, the 2 nd Generation RLV Level 1 Program 
Requirements document serves as the “parent” document for the SRD, whose 
content can be traced directly to Level 1 Requirements. For example, Level 1 


Requirements include a probability of no greater than 1 in 10,000 for loss of crew 
in a mission. The SRD will transform this probability into reliability and 
redundancy requirements at the system level, which will subsequently be 
allocated to the elements of the architecture. In this way, the requirements for 
individual system components can be derived by successively refining the 
requirements to lower and lower levels of detail. 

As previously discussed, the Program includes various technology development 
projects. NASA’s success in advancing the state of the art in these key 
technologies as it pertains to safety and cost effectiveness will enable those 
goals. Conversely, the extent to which the state of the art can be advanced in 
these technologies will also constrain the candidate system architectures. For 
instance, if an engine cannot be developed that is sufficiently safe and 
economical, the Program will not meet its safety and cost goals. However, the 
definition of “sufficient” safety and economic needs for engines varies between 
candidate architectures. Hence, while the architectures drive the technologies, 
the technologies constrain the architectures. 

A requirements synthesis process has been developed to both assure that 
technology development is responsive to the needs of the candidate 
architectures and to mutually assure that the architectures are based on 
technologies that can be realized. The relationship between SRD development 
and technology development requirements is illustrated in Figure 11. The 
requirements synthesis process, illustrated in Figure 12, begins with the 
technology project’s identification of key technical parameters. 



Figure 5. Relationship between Systems Requirements Document 
development and technology development requirements. 
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Figure 6. Requirements synthesis process. 


Data for the technical parameters are then collected for the various candidate 
architectures and synthesized into a single set that spans, as much as possible, 
the candidate architectures. A convergence analysis of these synthesized 
architecture requirements against the technology project’s requirements identifies 
areas of divergence between the architectural needs and the planned technology 
developments. These divergences are then managed as Program risks, and are 
either accepted as a risk or mitigated in some manner, such as changing the 
technology project’s scope or imposing a constraint on the system architectures. 

The requirements synthesis process is iterative, with the cycle driven by key 
Program and project milestones, such as design reviews. This process: (1) 
assures that the systems requirements are feasible, with a known level of 
technical risk, and (2) provides technology development project objectives and 
priorities. 


3.2 Technology Performance Measurement 
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3.2 Technology Performance Measurements (TPMs) 


The TPM is a methodology that charts the history of the values of a selected set 
of requirements quantifiable in time for the purpose of clearly illustrating the 
changes in value in relation to Program/Project events and goals for that 
requirement value. A set of Technology Performance Measurements (TPMs) for 
each of the 2 nd Generation Reusable Launch Vehicle (RLV) program technology 
tasks are being developed, baselined and maintained by Systems Engineering. 

Each Technology Project provides monthly inputs for architecture contractor- 
identified TPMs that are applicable to their proposed concepts and within scope 
of the technology task. To assess the technology risk, a unique TPM chart will 
be used to track historical values and clearly illustrate progress against assigned 
threshold and objective values. Also, the TPMs will have tracebility to the 
Technology Project requirements, which will be maintained in a Systems 
Engineering requirements database. The TPMs provide technology health status 
data, architecture relevancy & integration data, and an application for cost and 
risk mitigation information for Program goals and objectives. 



TPM Working Group TPM Working Group TPMWG, RST’s 



Control 

Database 
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3.3 Systems Analysis 


Rigorous system analysis will indicate whether a system configuration, such as a 
candidate 2 nd Generation RLV architecture, will satisfy requirements. The 
systems analysis process addresses five criteria, as shown in Figure 13: 

1. Technical Viability 

2. Technology Risk 

3. Design Reference Missions 

4. Safety/Reliability 

5. Cost/Economics. 
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Figure 7. Criteria addressed by the systems analysis process. 










Obviously, the first step in an architecture systems analysis is to model the 
system and determine whether it is credible from a physical science viewpoint. 
This series of analyses will answer rudimentary questions such as “Can it reach 
orbit?” and “Will it survive the natural environment?” 

Given that the configuration possesses credible physics and processes, systems 
analyses then focus on the technology readiness levels (TRL) of the various 
architecture elements. This series of analyses answers questions such as “Will 
the technology be ready in time?” and “What is the impact if the technology does 
not achieve performance goals?” The risk reduction technology projects and the 
mission requirements synthesis process provide data to reduce uncertainty in 
these analyses. 

Given a candidate architecture that possesses credible physics/processes and 
realistic technology assumptions, the next set of analyses address the system’s 
functionality across the spread of operational scenarios characterized by the 
design reference missions. The safety/reliability and cost/economics associated 
with operating the system will also be modeled and analyzed to answer the 
questions “How safe is it?” and “How much will it cost to acquire and operate?” 
The parameters included in the systems analysis process are depicted in Figure 
13. Note also that the mission-level FOMs discussed in Section 2.1 are a subset 
of the systems analysis parameter set. 

Repeating the systems analysis process for a large number of candidate 
architectures will validate the systems requirements. For example, if multiple 
architectures meet the 1 -in-1 0,000 loss of crew requirement, it may be assumed 
this is a valid requirement that can be met by the 2 nd Generation RLV when it is 
developed and operational. Conversely, if a requirement cannot be validated in 
that no candidate system architectures meet the requirement, the systems 
analysis process provides for requirements “push-back” to establish a valid 
requirement. Because the requirements are allocated across multiple 
architectural elements and based on assumed performance of various 
technologies, requirements “push-back” will lead to a requirement reallocation or 
relaxation for the architectural elements and/or the technologies, which prompts 
a new analysis. 

One iteration of the systems analysis process is called a design analysis cycle. 
Over time, the character of DACs will evolve, growing in fidelity and precision; as 
it becomes available, test data resulting from risk reduction technology projects 
will be included in the DACs. In the near term, DACs will focus on the evaluation 
of a large number of candidate system architectures (refer to Figure 4). 
Subsequently, the DACs’ focus will shift toward greater detail on a smaller 
number of candidate architectures. Accordingly, the systems requirements 
validation will approach completion and the validation focus will shift to lower-tier 
requirements associated with architectural elements, subsystems, and 


components. Likewise, the mission-level FOMs will begin to stabilize and 
generally exhibit reduced variability over time. In this way, the systems analysis 
process: (1) validates systems requirements, and (2) determines the relative 
merit of various candidate systems architectures and technologies. 


4.0 


Summary 



■ Provided overview of SLI, setting context for approach 

■ Reviewed technology drivers 

■ Discussed overall SE&I approach 

■ Discussed technology readiness levels, requirements development & 
synthesis, technology performance measurement, and systems analysis 
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